General: Forums subtopic: App & System Services > Networking DevForums tag: Network Extension Network Extension framework documentation Routing your VPN network traffic article Filtering traffic by URL sample code Filtering Network Traffic sample code TN3120 Expected use cases for Network Extension packet tunnel providers technote TN3134 Network Extension provider deployment technote TN3165 Packet Filter is not API technote Network Extension and VPN Glossary forums post Debugging a Network Extension Provider forums post Exporting a Developer ID Network Extension forums post Network Extension Framework Entitlements forums post Network Extension vs ad hoc techniques on macOS forums post Network Extension Provider Packaging forums post NWEndpoint History and Advice forums post Extra-ordinary Networking forums post Wi-Fi management: Understanding NEHotspotConfigurationErrorInternal forums post See also Networking Resources for general networking resources, including information about Wi-Fi. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com"

Hi all, I've run into a kernel deadlock issue involving content filter + VPN system/network extension on macOS 26, and would really appreciate any insights. A user reported that their mac is occasionally assigened a 169.254.0.0/16 address and can't reach any website after connecting Wi-Fi. Disabling our content filter restores network connectivity immediately. They're running the following software on the mac: macOS 26 (issue reproduced on 25C56 and 25F71) NEFilterDataProvider-based content filter (our extension) VPN network extension A spindump taken while the system had lost network connectivity shows the content filter's process stuck while delivering an "allow" verdict to the kernel. All subsequent flow decisions for the extensions are blocked behind it, which would explain why new DHCP request can't complete and the interface stays on a self-assigned address. Based on the "last ran" and timestamp in the spindump, the underlying deadlock appears to have occurred while the computer wasn't connected to any Wi-Fi network, so there was no visible symptom at the time. The user only noticed something was wrong once they tried to reconnect and saw the bad IP address; they did not realize the content filter was already stuck. This issue may be identified by searching for keyword "sofreelastref" in the spindump (see comment below). Has anyone else seen a content filter + VPN hang like this on macOS 26? Any guidance or pointers would be greatly appreciated. Thanks in advance! For Developer Technical Support staffs: FB23720745 Shay

Hi, We are currently testing our Network Extension based solution on macOS 27 Beta and have observed some unexpected networking behavior. We would like to know whether other developers have encountered similar issues, or whether there are any known changes in macOS 27 Beta that may affect NEFilterDataProvider. Environment macOS 27 Beta (tested on multiple Beta versions) System Extension Network Extension NEFilterDataProvider (Content Filter) Xcode Beta Current Implementation Our product uses NEFilterDataProvider for network traffic filtering. To eliminate the possibility that our filtering logic is causing the issue, we created a minimal implementation. The current provider behavior: Only handles TCP 80/443 flows Does not inspect payload content Does not perform URL filtering Does not perform domain matching Does not apply any block rules Does not modify network traffic All flows are immediately allowed Example: handleNewFlow() | | return .allow() The issue can still be reproduced when all flows are returned with .allow(). The Network Extension is only performing basic flow handling without any filtering decisions. Observed Behavior On macOS 27 Beta, we can still reproduce networking issues with this minimal implementation. Observed symptoms include: Intermittent network connectivity issues DNS requests timing out or failing Some applications losing network access Chrome / Chromium-based applications are affected more frequently Safari sometimes continues working normally Disabling the Network Extension usually restores network connectivity Restarting or reloading the provider may require a significant amount of time before networking fully recovers The issue appears to be independent of filtering decisions, because: No traffic is blocked No complex policy evaluation is performed No packet modification is performed All flows are allowed Possible Areas Based on our investigation, we suspect this may be related to changes in: NEFilterDataProvider lifecycle handling Interaction between Network Extension and the system networking stack Network recovery behavior after provider restart/reload Possible changes in networking components such as NECP, networkd, or DNS handling Questions Has anyone observed similar behavior with NEFilterDataProvider on macOS 27 Beta? Are there any known compatibility considerations for Network Extension or Content Filter providers on macOS 27 Beta? Have there been any changes to Network Extension lifecycle management or networking behavior that developers should be aware of? Are there recommended debugging steps or diagnostic information that would help investigate this issue? We can provide additional information if needed: sysdiagnose Console logs Network Extension logs Sample project Feedback Assistant ID Thank you.

Since updating to macOS 27 beta 3 (build 26A5378j), my Mac is unable to establish any new TCP connections. This affects all outbound traffic regardless of destination or protocol, while ICMP (ping) continues to work normally. Steps to reproduce: Update to macOS 27 beta 3 (26A5378j) Connect to a standard home Wi-Fi network (no VPN, no proxy, no enterprise MDM profile) Attempt any outbound TCP connection (curl, git pull, ssh) Expected behavior: Connections to any HTTPS endpoint or SSH server should establish normally. Actual behavior: curl -4 -v https://github.com curl -4 -v https://google.com both hang indefinitely at "Trying [IP]..." — the TCP handshake never completes git pull over both HTTPS and SSH remotes times out with "Failed to connect... Timeout was reached" ping github.com and ping google.com both succeed normally and immediately This confirms the issue is isolated to TCP connection establishment, not DNS resolution or general network connectivity Issue persists identically across multiple reboots System info: macOS 27.0 beta 3, build 26A5378j Connected via personal home Wi-Fi (Bbox router) No VPN, no proxy, no enterprise security software Additional context: Multiple other users have reported identical symptoms on this same build across MacRumors forums and Reddit, describing broken connections in Firefox, Opera, Dropbox, Telegram, and Music/iTunes purchases, while Safari continues to work. Reported workarounds from other affected users include: Disabling "Limit IP Address Tracking" on the network interface Disabling all Network Extensions under System Settings → General → Login Items & Extensions Uninstalling CrowdStrike Falcon or similar EDR/security software (where present) This was working correctly on both beta 1 and beta 2, the regression appears to have been introduced specifically in beta 3.

Hi! We're developing a security product that uses both EndpointSecurity.framework to intercept and authorize process and file events; and NetworkExtension.framework o intercept and inspect network connections. We're occasionally seeing crashes caused by Endpoint Security timeouts. After investigating several crash reports, we believe we've identified a deadlock involving code signature verification: our Network Extension intercepts connections initiated by nsurlsessiond to retrieve OCSP/CRL data (we believe these requests are made on behalf of trustd during code signature validation). To determine which policy should be applied to an intercepted connection, our Network Extension verifies the code signature of the originating process. However, that code signature verification itself blocks while waiting for the OCSP/CRL requests to complete. Since those requests are being intercepted by our Network Extension, we end up with a circular dependency: A process requires code signature verification. Signature verification triggers OCSP/CRL network requests. Those requests are intercepted by our Network Extension. Our Network Extension attempts to verify the initiator's code signature before allowing the connection. That verification waits for the same OCSP/CRL requests to complete. As a result, code signature verification becomes blocked process-wide, including verification performed while handling Endpoint Security events. Eventually, our Endpoint Security client exceeds the allowed response timeout and is terminated. We're considering bypassing interception for OCSP/CRL traffic to avoid this deadlock, but we'd like to understand whether this is the recommended or most robust approach. Questions Is there a reliable way to identify network connections that are fetching OCSP or CRL data for code signature validation? What is the relationship between trustd and nsurlsessiond for these requests? Is there a dedicated nsurlsessiond instance serving trustd, or are these requests performed by the shared system/session-wide nsurlsessiond? Would it be a reasonable and future-proof approach to identify these requests by checking NEAppProxyFlow.remoteHostname (for example, ocsp.apple.com and crl.apple.com) and bypassing interception for those connections? Is there another recommended approach to avoid this deadlock when combining Endpoint Security and Network Extension in this way? Any guidance or best practices would be greatly appreciated. Thank you!

I’m building an iOS app that uses a Network Extension Content Filter provider. The app works when installed directly on a physical device from Xcode/development builds, but the same flow fails in TestFlight/App Store distribution builds. Main app bundle ID: com.project.betcontrolMain Network extension bundle ID: com.project.betcontrolMain.DNSFilterExtension Team ID: 74YN2U5NR9 The extension is embedded at: Runner.app/PlugIns/DNSFilterExtension.appex Both the containing app and extension are signed with: com.apple.developer.networking.networkextension = content-filter-provider The app also has Family Controls Distribution enabled. At runtime, enabling the content filter with NEFilterManager fails in TestFlight with: NEFilterErrorDomain code 5 - permission denied The same code path works when installed locally from Xcode. The code roughly does: NEFilterManager.shared().loadFromPreferences { error in let manager = NEFilterManager.shared() let providerConfiguration = NEFilterProviderConfiguration() providerConfiguration.filterBrowsers = true providerConfiguration.filterSockets = true providerConfiguration.vendorConfiguration = [:] manager.localizedDescription = "BetControl Website Shield" manager.providerConfiguration

Has anyone successfully requested an OHTTP Relay for URL filtering and got it approved? I first applied for a relay about a month ago, and it was rejected in the first 24h, apparently the DNS TXT record doesn’t have to be setup at the apex domain but at the PIR subdomain (or at least that’s my assumption because Apple doesn’t tell you). After correction the issue and resubmitting the request I haven’t heard back, it’s been in review for many weeks already. Has anyone experienced this kind of delay or has anyone gotten the relay approved?

We are implementing a Transparent Proxy for HTTPS (via TCP and QUIC). The following rules are set in startProxy: settings.includedNetworkRules = [ NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), prefix: 0, protocol: .TCP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "::", port: "443"), prefix: 0, protocol: .TCP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), prefix: 0, protocol: .UDP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "::", port: "443"), prefix: 0, protocol: .UDP) ] Handling TCP connections seems to work fine. But opening UDP flows from Chrome (or Brave) always fails with Error Domain=NEAppProxyFlowErrorDomain Code=2 "The peer closed the flow" (Doing the same for Firefox works!) BTW: We first create a remote UDP connection (using the Network framework) and when it is in the ready state, we use connection?.currentPath?.localEndpoint as the localEndpoint parameter in the open method of the flow. Is it a known issue that QUIC connections from Chrome cannot be handled by a Transparent Proxy Provider?

We are using a Content Filter Network Extension to perform telemetry over the network activity of enterprise iOS devices. The filter itself is not blocking any connection. We encountered an issue where our Content Filter got stuck in a deadlock in the startFilter method of the NEFilterControlProvider. This resulted in a crash report where we see 64 threads stuck in the startFilter call. While the content filter was stuck in a deadlock, the device network connectivity was lost. We solved the deadlock issue coming from our logger, however, we would like to get a better understanding on the following points: What are the critical paths where a Content Filter can have a device wide impact on network connectivity? What is the behavior of the OS when the Content Filter is unresponsive (e.g. in startFilter, handle(Report), handleNewFlow)? Will it try to start the filter again? Force kill it ? We saw that startFilter was called multiple times in our crash reports whereas we expected it to be called only on vendor configuration changes. What is the lifecycle of the filter control provider and filter data provider ? When are the different methods like startFilter called ? We would like our Content Filter to never cause disruptions and implement a circuit breaker behavior in case any issue occurs. Do you have any recommendation on how to achieve this ?

I’m encountering a persistent issue with my Network Extension (specifically NEFilterDataProvider) and would really appreciate any insights. The extension generally works as expected, but after some time — especially after sleep/wake cycles or network changes — a global network outage occurs. During this state, no network traffic works: pings fail, browsers can’t load pages, etc. As soon as I stop the extension (by disabling it in System Preferences), the network immediately recovers. If I re-enable it, the outage returns instantly. I’ve also noticed that once this happens, the extension stops receiving callbacks like handleNewFlow(), and reinstalling the app or restarting the extension doesn’t help. The only thing that resolves the issue is rebooting the system. After reboot, the extension works fine again — until the problem reoccurs later. I asked AI about this behavior, and it suggested the possibility that the kernel might have marked the extension as untrusted, causing the system to intentionally block all network traffic as a safety mechanism. Has anyone experienced similar behavior with NEFilterDataProvider? Could there be a way to detect or prevent this state without rebooting? Is there any logging or diagnostic data I should collect when it happens again? Any guidance or pointers would be greatly appreciated. Thanks in advance!

We are using the NEHotspotConfigurationManager to programmatically connect to a specific Wi-Fi network for a limited period of time. From iOS 26, this now triggers a Passwords prompt asking the user if they want to save the Wi-Fi settings in the Passwords app. There are two problems with this:- We are temporarily connecting for a specific purpose and this network is not intended for the user to connect to again The prompt even appears if the credentials are incorrect and the Wi-Fi network cannot be joined While I can see some benefit to this dialog for a user connecting to a new network, it should not be displayed when programmatically connecting, or at least there should be the ability to disable it. Secondly, it seems like an obvious bug that the dialog is shown before the Wi-Fi connection successfully connects - why offer the user to store invalid credentials?

We are developing a DLP agent that uses a NETransparentProxyProvider to perform traffic inspection and modification. Our architecture currently includes: LaunchAgent, which monitors user session activity (login/logout, session activation) Container App, which: installs and activates a System Extension creates and saves the NETransparentProxyManager configuration starts the transparent proxy via startVPNTunnel. We would like to automate the startup of the Transparent Proxy for all users, including newly created users, in a way that is fully supported by macOS. We are looking for official guidance on the correct and supported mechanism for starting a user‑level Network Extension (specifically NETransparentProxyProvider) automatically at user login. Questions: What is the recommended and supported way to automatically start a NETransparentProxyProvider at user login? Are there any constraints or best practices we should follow when designing an automatic startup flow for a Network Extension such as NETransparentProxyProvider? We would appreciate official clarification on the supported deployment patterns for starting a user‑level Transparent Proxy Network Extension automatically in multi‑user enterprise environments.

We got a feedback from apple side for our new request PIR server responded, but the canary value is not in the dataset. "www.apple.com/url-filter-test" should be set to 1 So we have validated this using our iOS app pointing to same environment and it is blocking this URL as per expectation as well as we have validated this using below curl docker exec pir-server sh -lc 'grep -n "www.apple.com/url-filter-test" /pir/data/input.txtpb; ls -l /pir/data/input.txtpb /pir/data/url-0.bin /pir/data/url-0.params.txtpb'; curl -sS -i https://ohttp.protectuswebfilter.com/.well-known/private-token-issuer-directory | sed -n '1,40p' Please help us, how they are validating this entry is available or not

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for one organisation app and it gets approved, so can I re submit the request with different bundle ID for other organisation and same PIR server, same OHTTP server ? Or do we need different domain name ?

We are building a NETransparentProxyProvider system extension on macOS. The extension needs a certificate identity provisioned by MDM for cryptographic operations at runtime (signing and/or mTLS). We have hit a wall where a PKCS#12-delivered identity resolves correctly inside the extension but an ACME-delivered identity does not, and we want to understand whether this is a known limitation, a gap, or whether there is a supported path we are missing. We understand the implications of the data protection keychain on macOS but wonder if there is a carveout here that may not be documented well. We deploy the extension via MDM (profile traditionally but could be via DDM on macOS27). A VPN profile delivers an identity reference to the extension at runtime via PayloadCertificateUUID which surfaces an identity reference within protocolConfiguration.identityReference. When referencing a PKCS#12 identity (com.apple.security.pkcs12 payload): the identityReference is 196 bytes, beginning with the 4-byte prefix 73737569 (ASCII "ssui"). The reference is self-describing — it embeds the keychain path (/Library/Keychains/System.keychain), the certificate subject (in our case, "Delegate Test CA"), the team ID, and a 20-byte SHA-1 hash at the tail. This format carries everything the Security framework needs to locate the item. Full reference (our test, redacted to structure): 73737569 00000020 <uuid-bytes> 00000000000000000000000000000006 64626e6d 00000023 2f4c696272…53797374656d2e6b6579636861696e00 ← /Library/Keychains/System.keychain 6974656d 00000069 80001000… ← item data incl. DER subject … 00000014 48b494ae47d1b7b07ed8c77a681337a3af8e92a8 ← 20-byte SHA-1 hash When referencing a ACME identity (com.apple.security.acme payload, ECSECPrimeRandom P-384, SE-backed): the identityReference is 20 bytes, beginning with the 4-byte prefix 63657274 (ASCII "cert"). The remaining 16 bytes are opaque — they do not embed a keychain path, certificate subject, or any other locator. Full reference (our test): 63657274 a4c7e569737944b1 ad464dc3bb398f14 Searching for the SecIdentity The PKCS#12 reference resolves using SecItemCopyMatching with kSecValuePersistentRef set to the 196-byte reference and kSecMatchSearchList pointing at System.keychain succeeds immediately, returning a SecIdentity with both SecIdentityCopyCertificate and SecIdentityCopyPrivateKey succeeding - this is obviously expected for an exportable software key type. The ACME reference fails using every path that we tried to search/load it as a SecIdentity. Primarily: kSecValuePersistentRef with kSecUseDataProtectionKeychain: true (no explicit keychain): -25291 (errSecNoDefaultKeychain) kSecValuePersistentRef with an explicit kSecMatchSearchList pointing at System.keychain: -50 (errSecParam) — combining kSecValuePersistentRef with an explicit keychain search list is an invalid parameter combination for the compact cert-format reference. kSecMatchItemList with an explicit kSecMatchSearchList: -25300 (errSecItemNotFound) SecKeychainItemCopyFromPersistentReference (legacy API): -25300 (errSecItemNotFound) kSecValuePersistentRef with no keychain qualifier at all: -25291 (errSecNoDefaultKeychain) com.apple.managed.vpn.shared access group (which i know has had entitled use on iOS): -34018 (errSecMissingEntitlement) Next steps The cert-format kSecValuePersistentRef produced by an ACME identity cannot be resolved in a root daemon context using any API path we can find. The ssui-format reference from a PKCS#12 identity works. With macOS 27, com.apple.configuration.network.vpn.vpn-plugin DDM declarations accept an Authentication.IdentityAssetReference which can point at an ACME identity asset. Traditional VPN profiles also support PayloadCertificateUUID referencing an ACME payload. Both paths result in the extension receiving a cert-format reference that it cannot resolve. Is there a supported API to resolve a cert-format kSecValuePersistentRef in a daemon context without a default keychain? Or is this just the reality of the DPK on macOS where ACME/SE-backed identities are not usable from system extensions, and the IdentityAssetReference and PayloadCertificateUUID fields only work for PKCS#12 or SCEP identity types in this context? For completeness: we have also explored ManagedApp.framework and ManagedAppIdentitiesProvider as an alternative delivery path, and believe this is the better method, but that hits a separate issue where managedappsd fails to verify the code signature of a system extension caller (filed separately as feedback FB23484530). Similar to this, we need to understand if the ExtensionConfigs in ManagedApp.framework are for appex user space app extensions only, and don't extend to System Extensions.

(Also submitted as FB23072541) iOS 27 beta 1 brings a brand new error which ends up resulting in a state of .serverSetupIncomplete: <NEPIRChecker: 0x7de6c79b60>: -[NEPIRChecker start:responseQueue:completionHandler:]_block_invoke - PIR status returned error <Error Domain=com.apple.CipherML Code=1100 "Unable to query status due to errors: Error details were logged and redacted." UserInfo={NSLocalizedDescription=Unable to query status due to errors: Error details were logged and redacted., NSUnderlyingError=0x7de712f4e0 {Error Domain=com.apple.CipherML Code=1800 "Error details were logged and redacted." UserInfo={NSLocalizedDescription=Error details were logged and redacted.}}}> <NEAgentURLFilterExtension: 0x7de6d24e60>: -[NEAgentURLFilterExtension startURLFilter]_block_invoke - Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> What’s a NEMembershipChecker? Member of what? Digging deeper I found these: Failed to prefetch tokens for group 'site.kaylees.Wipr2': Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125a40 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} queryStatus(for:options:) threw an error: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_NSURLErrorNWPathKey=satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, LQM: good, NSErrorFailingURLKey=https://pirissuer.kaylees.site/token-key-for-user-token, NSUnderlyingError=0x7517125b00 {Error Domain=NSPOSIXErrorDomain Code=50 "Network is down" UserInfo={NSDescription=Network is down}}, _NSURLErrorPrivacyProxyFailureKey=true, NSLocalizedDescription=The Internet connection appears to be offline.} The connection and the URL mentioned are fine of course, but "Network is down” now? This new problem only affects the App Store version of my app – not present if I install from Xcode. Users report that oddly, having an active VPN on the device works around this bug.

Hi, Our project is a MacOS SwiftUI GUI application that bundles a System Network Extension, signed with a Developer ID certificate for distribution outside of the app store. The system network extension is used to write a packet tunnel provider. The signing of the app & network extension is handled by XCode (v16.0.0), we do not run codesign ourselves. We have no issues with XPC or the system network extension during normal usage, nor when the application is installed on a user's device for the first time. The problem only arises when the user upgrades the application. I have experienced this issue myself, as have our users. It's been reported on Apple Silicon macbooks running at least macOS 15.3.2. Much like the SimpleFirewall example (which we used as a reference), we use XPC for basic communication of state between the app and NE. These XPC connections stop working when the user installs a new version of the app, with OS logs from the process indicating that the connection is immediately invalidated. Subsequent connection attempts are also immediately invalidated. Toggling the VPN in system settings (or via the app) does not resolve the problem, nor does restarting the app, nor does deleting and reinstalling the app, nor does restarting the device. The only reliable workaround is to delete the system extension in Login Items & Extensions, under Network Extensions. No device restart is necessary to garbage collect the old extension - once the extension is reapproved by the user, the XPC issue resolves itself. This would be an acceptable workaround were it possible to automate the deleting of the system extension, but that appears deliberately not possible, and requiring our users to do this each time they update is unreasonable. When the upgraded app is opened for the first time, the OSSystemExtensionRequest request is sent, and the outcome is that the previously installed system network extension is replaced, as both the CFBundleVersion and CFBundleShortVersionString differ. When this issue is encountered, the output of systemextensionsctl list shows the later version is installed and activated. I've been able to reproduce this bug on my personal laptop, with SIP on and systemextensionsctl developer off, but on my work laptop with SIP off and systemextensionsctl developer on (where the network extension is replaced on each activation request, instead of only when the version strings differ), I do not encounter this issue, which leads me to believe it has something to do with the notarization process. We notarize the pkg using xcrun notarytool, and then staple to the pkg. This is actually the same issue described in: https://developer.apple.com/forums/thread/711713 https://developer.apple.com/forums/thread/667597 https://developer.apple.com/forums/thread/742992 https://developer.apple.com/forums/thread/728063 but it's been a while since any of these threads were updated, and we've made attempts to address it off the suggestions in the threads to no avail. Those suggestions are: Switching to a .pkg installer from a .dmg As part of the .pkg preinstall, doing all of the following: Stopping the VPN (scutil --nc stop), shutting down the app (using osascript 'quit app id'), and deleting the app (which claims to delete the network extension, but not the approval in Login Items & Extensions remains??), by running rm -rf on the bundle in /Applications As part of the .pkg postinstall: Forcing macOS to ingest the App bundle's notarization ticket using spctl --assess. Ensuring NSXPCListener.resume() is called after autoreleasepool { NEProvider.startSystemExtensionMode() } (mentioned in a forum thread above as a fix, did not help.) One thing I'm particularly interested in is the outcome of this feedback assistant ticket, as I can't view it: FB11086599. It was shared on this forum in the first thread above, and supposedly describes the same issue. I almost find it hard to believe that this issue has been around for this many years without a workaround (there's system network extension apps out there that appear to work fine when updating, are they not using XPC?), so I wonder if there's a fix described in that FB ticket. Since I can't view that above feedback ticket, I've created my own: FB17032197

Hello, What are the restrictions on submitting apps to the mac App Store that use an NETransparentProxy alongside a locally installed and trusted Root-CA to intercept, decrypt and manipulate TLS traffic? To be more specific, I'm not talking about a Safari extension. I'm talking about system-wide traffic. So that the app can detect and block ads and trackers from all apps, not just Safari. I'm aware that such an app can be distributed using an unsandboxed Developer-ID signed app. But I wonder if such an app also breaks Sandbox requirements for AppStore distributed apps? Also, is there a way for a sandboxed app to install and trust a root CA? SecTrustSettingsSetTrustSettings does not work in Sandboxed apps from what I found. Finally, I want to ask about EndpointSecurity. Can this entitlement be used in AppStore-ditributed apps? Is doing any of these things possible on AppStore-distributed apps? Thanks in advance for your reply.

I'm building a gambling addiction recovery app for macOS that uses NEFilterDataProvider to block 208,000+ gambling domains system-wide. The app is already live on the iOS App Store under the same developer account. I need the restricted entitlement com.apple.developer.network-extension.content-filter to distribute via the Mac App Store. I submitted a request through Developer Support > Development and Technical Information > Rights/Entitlements (case #102914968660) on June 14th — 9 days ago with no response yet. My questions: Is this the correct channel for requesting this entitlement for Mac App Store distribution? Has anyone successfully obtained this entitlement? What channel/process worked for you? Is there a typical turnaround time I should expect? Any guidance appreciated. Thanks

Howdy, I've noticed a strange behavior recently on my macos (26.5.1) when using my System Extension-hosted Network Extension with a Packet Tunnel Provider inside: let dnsSettings = NEDNSOverHTTPSSettings(servers: ["8.8.8.8", "8.8.4.4"]) dnsSettings.serverURL = URL(string: "https://dns.google/dns-query") settings.dnsSettings = dnsSettings I have always expected this block to not need any DNS resolution, since IPs for dns.google are preconfigured, however not sure it's been the case lately. I see normal DNS requests to the addresses above to :53. Once resolved, no more DNS traffic, just :443 via TUN. Is it possible that some changes were introduced in the past months that would make macos to have to resolve dns.google with regular DNS before switching over to DoH?